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REMARKS/ARGUMENTS 



The present response is intended to be fully responsive to all points of 
objection and/or rejection raised by the Examiner and is believed to place the 
application in condition for allowance. Favorable reconsideration and allowance 
of the application is respectfully requested. 

Applicants assert that the present invention is new, non-obvious and 

useful. 

Objections to the Specification 

The specification has been objected to because the word "an" on page I 
line 7 is a typographical error and should be replaced by the word "a". Apphcant 
thanks the Examiner for tlie careful reading of the specification and has corrected 
the error (see attached amendments to the specification on page 2). Applicant 
therefore respectfully requests that the objection be withdrawn. 

Status of Claims and Support for Changes in the Claim Listing 
Claims 1-27 were originally pending in the application. 
Claims 1-27 were rejected. 
Claims 16, 18, 20, 24, and 26 are cancelled. 
Claims 1, 9-14,17, 19, 21, 25, and 27 are currently amended. 
Claims 28-32 are new. 

Any amendments and cancellations detailed here should riot be construed 
to have been made in order to overcome prior art unless specified otherwise. 

Claims have been amended or added in order to clarify the subject matter 
of the application. In making these revisions and additions, care has been taken to 
ensure that no new matter has been added.. The lines from the original 
specification are stated and/or reproduced below solely to demonstrate that no 
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new matter has been added, and therefore no limitations should be read into the 
claims based on these slated and/or reproduced specification lines. 

The claim amendments and new claims are supported by the originally 
filed specification, as follows: 

In claims 1, 12, 13, 21, 25, and 27 it has been clarified diat the worklist is 
a digital image communication in medicine (DICOM) modality worklist and that 
the worklist is generated by a hospital information system (HIS) or radiology 
inlbrmation system (RIS). Support for these amendments is found inter-alia on 
page 15, line 31 to page 16 line 2 and on page 15 lines 2-4: 

Refer to Fig. 7 which shows an example of a DICOM modality 
worklist 700, according to a preferred embodiment of the present 
invention. Worklist 700 can be considered a special format of generic 
worklist 200, adapted to conform to the DICOM standard. 

A radiology information system RIS 410 or alternatively a hospital 
information system HIS 410 functions as the information system for 
radiology or hospital patients and as the worklist geneiBtor. 

In claim 12 and 27, it has been further clarified that it is the hospital 
information system (HJS) or radiology information system (RIS) that is queried 
and that the DICOM modality worklist may schedule tasks for any type of 
modality (and not necessarily only for image acquisition machines). Support for 
these amendments is found inter-alia on page 15 lines 22-24 and on page 15 lines 



The worklist management service allows elements of system 400 to 
query the modahty worklist generator RIS or HIS 410 and receive the 
assigned tasks for each modality 420. 



In the dicom system, the modalities can be things other than image 
acquisition machines, such as ECG. 



7-8: 
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Claim 14 has been amended to specify that the hospital infomiation 
system (HIS) or radiology information system is configured to generate the 
worklist. Support for this amendment is found inter-alia on page 15 lines 2-4 
reproduced above. 

Claim 1 7 has been amended to clarify that the DTCOM standard is used for 
communication between the hospital information system (HIS) or radiology 
information system and the prefetcher. Support for this amendment is found inter- 
alia on page 15 lines 15-16: 

Communication between the different components of system 400 
follows the DICOM standard 450. 

Claim 19 has been transformed from an independent claim into a 
dependent claim on claim 13 where at least one modality is an image acquisition 
machine. This transformation into a dependent claim has been made because it 
was deemed that the dependent form was sufficient and in order to reduce the 
number of independent claims. Support for this amendment is found inter-alia in 
the original claim 19 and on page 15 line 5-8: 

In system 400, the modalities are image acquisition machines 420, for 
example x-ray machines, magnetic resonance imaging (MRIs), 
computed tomography (CTs), ECG etc. In the dicom system, the 
modalities can be things other than image acquisition machines, such 



In claims 9 and 10 the to faulty antecedent basis has been corrected. 

Claim 1 1 has been amended to delete the limitation of the worklist being a 
DICOM modality worklist since claim 1 on which claim 11 depends now 
specifies the worklist as a DiCOM modality worklist. 

Independent claim 28 has been added reciting a method of querying a 
hospital information system (HIS) or radiology information system (RIS) relating 
to at least one task for at least one modality scheduled by a DICOM worklist 



as ECG. 
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generated by the HIS or RIS and getting ready for the task. Independent claims 
31 and 32 describe a system and computer program product respectively which 
are counterparts to method claim 28. Support for these claims is found inter-alia 
on page 15 lines 22-31, on page 18 line 1 1-12, and inFigure 4: 

The worklist management service allows elements of system 400 to 
query the modality worklist generator RIS or HIS 410 and receive the 
assigned tasks for each modality 420. The rate of querying is 
configurable and may be the same or different for different elements 
of system 400. In addition the rate of querying may be the same or 
may differ for a particular querying element depending on factors such 
as how busy the querying element is, time of day, etc. The querying 
entity may be, for example each modality 420, so as to prepare for the 
expected task. In accordance with the present invention, prefetcher 
460 uses flie worklist management service to periodically query the 
worklist for tasks assigned to all modalities 420 and thereby predict 
storage use. 

In stage 540, prefetcher 460 queries HIS 410 ajid receives data on the 
assigned task. 

Dependent claim 29 has been added reciting one embodiment where the 
getting ready includes ensuring that in a faster access part of a medical stomge 
which includes a faster access part and a slower access part there is available at 
least some data which based on at least one predetermined rule is deemed Hkely to 
he accessed in connection to said at least one task which said DICOM modality 
worklist has scheduled said at least one modality to perform. Support for this new 
claim is found inter-alia on page 16 line 24 to page 17 line 10: 

In one embodiment, prefetcher 460 uses patient name 706, patient ID 
708, modality 718, scheduled station AE title tag 720, start date 722, 
start time 724, referring physician's name 710 and performing 
physician's name 730 to ensure that relevant data related to the 
assigned task is located in faster access storage part 432 of storage 
430. For example examiner component 310 of prefetcher 460 can 
examine modality 718 and title tag 720 and thereby determine using 
predetermined rules the type(s) of data which (generic) information 
consumers are likely to access for the assigned task. As another 
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example, examiner component 310 may designate referring physician 
(or other referring medical stafO 712 and/or performing physician (or 
other performing medical staff) 730 as Infonmation consumers 440 
and tailor the types of data accordingly. As another example, cross 
referencer component 320 of prefetcher 460 may use patient name 706 
and patient ID 708 to compare the types of data determined by 
examiner 310 with data actually stored for the identified patient. As 
another example, retriever component 330 may use start date 722 
and/or start time 724 as a deadline for retrieving any relevant data 
only stored in slower access part 434. In other embodiments, 
prefetcher 460 may use additional information on worklist 700, less 
information on worklist 700 and/or different information on worklist 
700 to ensure that relevant data related to the assigned task is located 
in faster access storage part 432 of storage 430. 



Dependent claim 30 has been added reciting one embodiment where the 
querying and preparing are performed by a vScheduled modality. Support for this 
amendment is foimd inter-alia on page 15 lines 27-28: 

The querying entity may be, for example each modality 420, so as to 
prepare for the expected task. 



Claim 16, 18, 20, 24, and 26 have been cancelled in order to present a 
concise new set of claims and so as to not incur additional expenses due to the 
new claims. No implication on the desirability, accuracy, novelty or inventive 
step of the cancelled claims should be construed from the cancellation. 

Claim Rejections 

35 us e, §112 Rejections 

In the office action, the Examiner rejected claims 9 and 10 under 35 U.S.C 
1 12, second paragraph, as being indefinite for failing to particularly point out and 
distinctly claim the subject matter which applicant regards as the invention. 
Specifically, claims 9 and 10 lacked proper antecedent basis due to inaccurate 
dependencies. Applicant thanks the Examiner for pointing out the inaccuracies in 
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these claims and has followed the Examiner's suggestions in amending claim 9 to 
depend on claim 8, and amending claim 10 to depend on clahn 9 (see claim listing 
for amendments). Applicant respectfully asserts that claim 9 and 10 as amended 
are proper under 35 USC 1 12 and requests that the rejection be withdrawn. 

35 as.a § 102 Rejecdons 

The Examiner has rejected claims 1-7 and 1 1-27 under 35 U.S.C 102(e) as 
being anticipated by Cooke, Jr. et al (US 6,574,629, hereinafter "Cooke**)- 

Applicant appreciates the time and consideration provided by the 
Examiner in reviewing this application, however, respectfully traverses the 
rejection of the claims at least for the following reasons. 

Anticipation under 35 U.S.C. 102 requires that each and every claimed 
feature be disclosed by a single prior art reference. 

Applicant respectfully states that Cooke neither teaches nor suggests a 
digital image communication in medicine (DICOM") modality worklist which is 
generated by a hospital information system ("HIS") or ("RIS") as recited in each 
of the independent claims 1, 12, 13, 21, 25, 27, 28, 31, and 32 currently pending 
in this application. 

As stated in the background section of the current application, in the 
related art, some smart medical storage management systems utilize Health Level 
7 (HL7) information to predict storage usage. However in some cases the HL7 
information is unavailable, inadequate, or too general. See for example page 2 
lines 1 to 16 of the current application reproduced here: 

The Health Level 7 (HL7) standard addresses the interfaces among 
various systems that send or receive patient admissions/registration, 
discharge or transfer (ADT) data, queries, resource and patient 
scheduling, orders, results, clinical observations, billing, master file 
update information, medical records, scheduling, patient referral, and 
patient care. Some smart medical storage management systems utilize 
HL7 information such as patient admission and discharge information 
in order to predict which stored data objects may be required (i.e. 
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predict storage usage). These storage management systems can then 
transfer those predicted data objects to a faster access storage. 
However HL7 information is not always available because HL7 is not 
supported by all hospitals, and even when available, HL7 information 
is not complete (for example while the HL7 order message may not 
provide the name of the image acquisition machine assigned to the 
patient nor the exact time for the procedure, it does provide the 
procedure's date and patient's details). In addition, because the HL7 
information (such as that passed in the HL7 admission message) is of a 
general nature, prediction of storage usage based on HL7 may result in 
caching more stored data objects than necessary. 

Cooke describes such a smart medical storage management system where 
HL7 information is transferred from the RIS. Only the transfer of HL7 
information from the RIS 44 to the RIS gateway/PACS broker 46 is illustrated in 
each figure depicting both RIS 44 and PACS broker/RlS gateway 46. For 
example, see Figure 1 and Figure 4 of Cooke. See also, for example colimm 13, 
lines 4 to 12 of Cooke (reproduced below) where it is specified that PACS broker 
46 communicates in HL-7 with the RIS. 

Specifically, PACS broker 46 is a stand-alone platform that listens to 
the RIS and responds to querv/retrieve statements from the PACS core 
components by accessing appropriate data from the RIS . To this end. 
PACS broker 46 is able to communicate in HL-7 ("Health Level 7) 
with the RIS and to conununicate in DICOM with network gateway 6. 
Thus, the PACS broker makes patient demographics , schedules, study 
parameters and reports on the RIS available to the core PACS 
components (underline added). 

It is evident from the above quote that in Cooke the communication with 
the RIS 44 is in HL-7. There is neither a hint nor an indication that any 
information other than HL-7 information is transferred from the RIS 44. Certainly 
there is no mention of a DICOM modality worklisl being available from the RIS 



It is also evident from the above quote that in Cooke all requests for 
information from the RIS 44 go through the RIS gateway/PACS broker 46. There 



44. 
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is no possibility of direct querying of the RIS 44 by the PACS. See also Cooke 
Column 22, lines 10 where it is stated that in order to obtain information from RIS 
44 a PACS bnoker/RIS gateway 46 is typically required: 

As described above, in order to obtain information from tbe HIS or 
RIS, a PACS broker (i.e. RIS gateway 46) is typically required on the 
PACS 



See also Cooke Column 18 lines 59 to 65 where the querying by the 
network gateway is via the PACS broker/RIS gateway 46: 

In more detail^ pre-felching involves RIS gateway 46 receiving 
information concerning a scheduled event from RIS 44, and then 
transmitting that information to the PACS, in particular to network 
gateway 6 (see FIG. 1). The network gateway then queries the RIS, 
via the RIS gateway, requesting details concerning the scheduled 
event. 



This requirement in Cooke to go through die RIS gateway/PACS broker 
46 (due to the necessity in Cooke of communicating with the RIS 44 in HL-7) 
may be viewed by some as a disadvantage of the system described in Cooke. 

To further distinguish Cooke from the invention recited in the independent 
claims, in Cooke worklist generadon is not p erformed by the RIS (or HIS). 
Instead, Cooke clearly states that worklist generation is performed by the 
reviewing stations. See for example, column 1 1 lines 41 to 54: 

The reviewing stations also perfonn automatic workUst generation and 
updates as relevant studies arrive. Regarding worklist generation, 
upon logging in to the PACS via a reviewing station, a user may enter 
a query asking the PACS to locate a study or group of studies based 
on input criteria, such as an accession number, which is a unique 
identifier for each study. Once these studies have been located, the 
PACS generates, and the reviewing station displays, a user interface 
called a main study window. This main study window is comprised of 
action buttons, system status indicators, and a main study list which 
includes studies that match the input criteria. The worklist comprises 
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the study, or group of studies, that the user selects from the main study 
list (underline added). 



See also for example column 35 lines 31 to 51 of Cooke: 

Worklist criteria section 353 permits the user to generate worlclists 
using only one mouse click bv clicking on a displayed action button . 
To this end, worklist criteria section 353 includes worklist selection 
rules button 360, which creates the worklist select button (see section 
3.1) in the main study list. Clicking on this button causes other buttons 
to appear, so long as they have been set in the user profile form. These 
buttons include send (display) button 361 which permits a user to 
view partially local studies that are in the process of being retrieved to 
the user's station; worklist cached button 362 which permits the user 
to select all cached studies in the PACS cluster that meet remaining 
criteria; relevant priors button 363 that allows the user to select 
relevant prior studies; priors match modality button 364 that allows 
the user to "fine-tune" selection of prior studies; priors match 
speciality button 365 that further "fine-tunes" selection of prior 
studies; select worklist specialty button 366 that permits the user to 
select studies based on body part; select acquisition station button 367 
that allows users to select studies from a particular imaging 
modalities, and study status button 368 for selecting a defaxilt status, 
(underline added) 

Furthermore, there is neither a hint nor an indication that the worklist 
described in Cooke is similar to the worklist of the current application. For 
example, Cooke talks about prefetching relevant studies to a reviewing station in 
column 18 lines 55-59. 

The present invention includes the ability to route relevant prior 
studies to a reviewing station in contemplation of a scheduled event, 
such as a patient examination or the like. This process is called pre- 
fetching , and is ellected by code executing on the network gateway, 
(underline added) 

Note that Cooke in Column 11 lines 53 to 54 specifically equates the 
worklist with the studies. 
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The worklist comprises the study, or group of studies, that the user 
selects from the main study list 

Therefore in contrast to one embodiment of the current invention where 
the worklist is used in ensuring that data deemed likely to be accessed is available 
in a faster access part, in Cooke it is the relevant worklists which are prefetched. 
This distinction is further proof that the woiklist of the invention of the current 
application differs from the worklist described in Cooke. 

To summarize, in Cooke there is neither a hint nor an indication of 
DICOM modality worklist generation by the RIS ox HIS, an hnportant feature of 
the current invention. This feature is recited in each of the independent claims 1, 
12, 13, 21, 25, 27, 28, 31, and 32 currently pending in this application, as 
presented in the claim listing above. Applicant therefore respectfully asserts that 
each of independent claims 1, 12, 13, 21. 25, 27, 28, 31, and 32 are allowable. 
Dependent claims 2-11, 14-15, 17, 19,21-23, and 29-30 which depend dirwtly or 
indirectly from the independent claims therefore include the hmitations of the 
independent claims. Applicant therefore respectfully asserts that tlie dependent 
claims are also allowable. 

Applicants believe the remarks presented hereinabove to be fully 
responsive to all of the grounds of rejection raised by the Examiner. In view of 
these remarks. Applicants respectfully submit that the specification and all of the 
claims in the present application are in order for allowance. Notice to this effect is 
hereby requested. 

Please charge any fees associated with this paper to deposit account No. 
09-0468. 
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Respectfully submitted. 



By: j^^^ — >^ 

Stephen C. Kaufinan 

Reg. No. 29,551 

Phone No. (914) 945-3 197 

Dale: May 1, 2006 

IBM Corporation 

Intellectual Property Law Dept. 

P. O. Box 218 

Yorktown Heights, New York 10598 
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